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APPLICATION MANAGEMENT FOR MULTI APPLICATION DEVICES 
Technical Field 

The present invention relates to the management of applications resident 
on multi application devices, for example smartcards and smartcard terminals. It 
5 has particular but not exclusive application to situations where the device owner 
and the provider of applications are arms length parties. 
Background 

Smartcards are increasingly used and proposed to be used in many 
different applications. By smartcard is meant a device including processing 
10 capacity intended for use in association with terminals or similar infrastructure. 
The smartcards may operate by direct electrical contact or via a wireless 
mechanism. 

Advances in technology, and in particular the amount of processing 
power and memory resident on reasonably priced smartcards, have seen 

15 proposals advanced for multi application smartcards. Such a smartcard is one 
where there is not only a single software application, for example a credit card 
application, but a variety of other applications on the same card. These may in 
principle include access applications, telephone applications, airline 
applications, rental car applications, loyalty schemes, and many others. A 

20 particular advantage of having many applications resident on a smartcard is that 
the user can minimise the number of separate cards which need to be carried. It 
also allows the issuer of the cards to derive revenue from having applications 
from third parties resident on the card, and to defray the capital cost of issuing 
the cards. For example, an airline may issue a smartcard as part of a loyalty 

25 scheme, and receive revenue by allowing a financial services institution to place 
a credit card application on the card. 

Multi application smartcards are a means by which applications can be 
loaded which have functionality well beyond the traditionally foreseen smartcard 
applications, as it is possible for quite small applications to be economically 

30 provided on the card. 

For example, US patent Nos 5530232 and 5578808 to Taylor disclose 
multi application smartcard systems. 



Another aspect of multi application systems is the requirement for 
terminals to appropriately interact with the various applications. Hence, if an 
application is to be loaded onto a card, then there needs to be a mechanism to 
provide the corresponding terminals with an interacting application. 
5 Multi application smartcard schemes present a number of specific 

problems, particularly where various parties have applications on the card 
which may contain confidential information, encryption keys or details which 
they do not wish disclosed to the other applications resident on the card. It is 
necessary for the application provider in these cases to trust the arrangements 

10 between it and the issuer, both commercially and technically, so that 
unauthorised information is not disclosed. Another issue for the card owner and 
application providers is to ensure that applications on the card do not interfere 
with each other, for example by overwriting memory in use by another 
application. A further issue for the issuer is that in many cases they will wish to 

1 5 ensure that inappropriate or competing applications are not loaded onto the 
card. For example, a financial institution issuing a smartcard is unlikely to desire 
that the applications of other financial services providers be loaded onto the 
smartcard. 

US patent No. 5544246 to Mandelbaum et al describes a particular type 
20 of smartcard operating system which allows different service providers' 
applications to coexist on a smartcard. Essentially, this proposes a UNIX type 
solution, where each user has control over a particular sub-directory in the card 
operating environment. The issuer, or super user, has only limited ability to 
access the sub-directories associated with other application providers. A 
25 particular problem with this arrangement is that it leaves control of which 
applications are loaded to the card issuer. This means that the card issuer 
needs to be directly involved with each application which is loaded on the card. 
It does not provide a mechanism for loading applications onto cards owned by 
different issuers. A further issue is that the application providers are entirely 
30 reliant on the security and integrity of the card issuer. 

It is an object of the present invention to provide a software system, which 
is independent of the card or terminal operating system and independent of the 



issuer, which can control loading and removal of applications, so as to facilitate 
an orderly and accessible market for parties wishing to load applications onto 
cards owned by one or more issuers. 
Summary of the Invention 

According to one aspect, the present invention provides an independent 
software system which enables the remote loading and unloading of 
applications. In operation, a control server maintains details of the devices 
which the system controls, a set of possible applications which can be loaded 
onto the devices, and a control means which determines which applications are 
permitted or required to be loaded onto which devices. When a device is 
brought on line with the server, for example by a customer inserting a card into a 
terminal, the terminal sends a signal to the control server which identifies the 
device. The control server matches the identification to its records, and 
determines whether a new application needs to be loaded, any of the existing 
applications need to be updated, or if an application needs to be removed. On 
the basis of this information, the control server and the terminal then cooperate 
to load or unload applications onto the smartcard. 

It will be appreciated that in some cases the application may be stored on 
the terminal and downloading simply authorised by the control server. In some 
cases, the terminal may act as a bare intermediary and simply load onto the 
card applications sent directly from the control server. 

At another level, in order to facilitate the market, the inventive system acts 
as an intermediary. A particular application provider may, for example, provide 
details of suitable or desired demographics to the system, and general 
details about the type of application proposed. The system will then 
determine the various sets of cards to which these criteria may be applicable. 
It is noted that these may spread across many different issuers, or be from a 
single issuer. The system then passes the specific requests to the card issuers, 
who then propose suitable contractual terms which are agreed with the 
application provider. A specific contract is entered into between the application 
provider and the issuer, which is administered by the intermediate party. Once 
this contract is in force, the control information is updated in the control server, 



and when next the cards are brought on line, the appropriate applications are 
downloaded. It is emphasised that the present invention provides a very flexible 
approach. For example, it readily facilitates time limited loading - an application 
may be purely an advertisement for an upcoming event. The term 
5 application in the context of this invention encompasses files, displays and 
advertising messages. 

The application provider may pay for this application to be downloaded 
so that it is displayed when the terminal is accessed by the card, for example, for 
a month. At the end of this period, the control server can remove this application 
1 0 from the card when next it is brought on-line. 

The present invention further provides various novel reporting structures 
and systems. For example, it facilitates reporting to an issuer what applications 
are loaded onto which cards, as well as reporting to an applications provider 
how many of its applications are loaded, on what types of cards, and the "rent" it 
1 5 is paying for the relevant space. 

It will be appreciated that references to cards could equally be to 
terminals or other similar devices - indeed, in many cases both would need to 
be controlled. 

The present invention is based upon the principle of managing the non- 
20 volatile memory space on the smartcard as if it were a piece of real estate. The 
control system acts as the real estate agent. The application for those wishing to 
rent space approach the real estate agent who then brokers a deal with the 
issuer. The agent then becomes responsible for ensuring rent is appropriately 
collected, and that the tenants do not interfere with each other. 
25 This is a very powerful paradigm, as it allows for the conventions and 

processes evolved over a long period for lessees and owners of premises to be 
applied to the residence of applications on smartcards. Accordingly, concepts 
familiar to business managers can be applied and the process managed on a 
fair and equitable basis, to the benefit of both the application providers and the 
30 device owners. 



Brief Description of Drawings 

An embodiment of the present invention will now be described with 
reference to the accompanying figures, in which: 

Figure 1 is a general overview schematic diagram showing the context of 
5 the inventive system; 

Figure 2 is a block diagram illustrating the software components of the 
cards and terminal according to the inventive system; 

Figure 3 is a schematic diagram showing the interactions required when 
a device issuer provides space on one or more on one or more devices for rent; 
10 Figure 4 is a schematic diagram showing the interactions required when 

an application provider wishes to rent space on one or more devices; 
Figure 5 shows a sample rental search request screen; 
Figure 6 shows a sample rental search results screen; 
Figure 7 shows a sample rental confirmation screen; 
1 5 Figure 8 shows a sample application report screen; 

Figure 9 is a schematic illustration of the interaction of devices when an 
application provider wishes to extend a lease; 

Figure 10 is a schematic illustration of the interaction of devices when a 
request to delete applications is sent; 
20 Figure 1 1 is a schematic illustration of the interaction of devices when an 

operator wishes to obtain details of a device; 

Figure 12 is a schematic illustration of the interaction of devices when an 
application provider wishes to add a new application to devices; 

Figure 13 shows a sample screen reporting applications to be 
25 downloaded; 

Figure 14 shows a sample screen reporting configuration for selected 
devices; 

Figure 15 shows a sample screen reporting lease agreements; 
Figure 1 6 shows a sample screen reporting devices by issuer; 
30 Figure 17 shows a sample screen reporting tenants current on the 

system; and 

Figure 18 shows a sample screen reporting vacant property on the 



system. 
Description 

It will be appreciated that the present invention is broad in scope and 
application, and that it may be implemented in diverse ways yet provide the 



5 same functionality. One illustrative embodiment will be described below. The 
following table sets out some of the analogies between the realtor/property 
interaction and the processes for use in multi use smartcard systems. 



Realty Term 


ALCS function analogy 


Owner 


Device Issuer, e.g. card issuer 


Realtor/Agent 


ALCS 


Lessee/Tenant 


Application owner 


Submitting new real estate 


Issuer advising updated list of e.g. cards 
issued to ALCS 


Submission of lease request 


Application provider requesting access to 
certain space or certain cards. 


Search for suitable real 
estate 


ALCS - mediated database search for cards 
meeting demographic requirements. 


Rental property 


Specified space on multi-application 
smartcard or terminal. 



From figure 1, it can be seen that the present invention provides an 
application lease control system (ALCS) 30 lying between the various devices, 

0 collectively referenced as 10, and the various participants having a stake in the 
effective operation of the system, referenced collectively as 50. Devices 10 
would generally include a large number of terminals , illustratively referenced 
as 1 1, 12, 13, which may be of different manufacture and operate under different 
operating systems. At each terminal, smartcards may be utilised which are 

5 compatible with the respective terminal, using for example either the Multos 
scheme 14, Javacard scheme 15 or OSSIA scheme 16. Each terminal is 
connected to its normal host, one of the participants 50, as well as to the 
application lease control system 30. 

The participants may include the owner of the card, the card issuer 51 , or 



in our analogy the real estate owner, for example a bank; developers of 
applications 52; the card tenants 53; the terminal issuer/owner/acquirer 54; and 
terminal tenants 55. It will be appreciated that some of these will have 
commercial relationships outside the context of the present invention - for 
5 example, the application providers will be contracted by card and terminal 
issuers 51,54 and by tenants 53,55 to provide the necessary applications and 
applications. The terminal owners 54 and card issuers 51 will have appropriate 
arrangements to facilitate the operation of the card issuer's 51 cards in the 
terminals of at least some of the terminal owners 54. 

1 0 The latter arrangements are well known and commonly implemented. It 

will be appreciated that a set of suitable legal agreements will need to be 
concluded prior to any party becoming a participant in the system, so as to 
define the respective legal rights and obligations of the parties. The ALCS 30 
and interacting software need to operate in a manner consistent with such 

15 agreements if the potential of the present invention is to be fully realised. The 
present invention is concerned with managing the available capacity of both 
cards and terminals, performing a role analogous to a real estate agent or 
realtor to set up and manage relationships between device issuers and tenants, 
or owners of applications. 

20 A variety of interfaces must be provided to allow the various participants 

50 to interact with the ALCS 30. Thus, appropriate interfaces need to be 
provided for the operators of the ALCS 30 and its components; interfaces for 
device issuers 54, 51; and interfaces for application providers, who may be 
tenants or their application developers, to deposit their applications for 

25 distribution to devices. The ALCS will also need to provide suitable interfaces to 
the participants, for example card issuer interface, device tenant interface, and 
terminal issuer. The ALCS 30 will also need to interface with the software 
running on the respective devices 10. Communications may be by any suitable 
mechanism between ALCS 30 , the devices 10, and participants 50, shown as 

30 cloud 35. These may include internet, mobile data networks, leased lines, DDN, 
POTS or other analogue networks or X25 

The ALCS 30 may be implemented by any suitable hardware. For 
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example, figure 1 shows the system 40 implemented via an NT server based 
system. Reports of various types can be generated, as described in more detail 
below, shown as block 37. Server 40 is in communications with a relational 
database 38, preferably implemented on a suitable server 39. It will be 
5 appreciated that the type and scale of the hardware will be dependant on the 
number of devices and applications which are managed by the system. 

In most areas where the ALCS 30 can be deployed, it will need to be able 
to support a range of different smartcard and terminal hardware devices. This is 
a consequence of the prevailing smartcard environment envisaged for the near 

1 0 future. Preferably, these will conform to prevailing standards, for example the 
Application Protocol Data Unit and Inter-Industry Commands of IS07816-4. The 
terminals 11-13 need to have, as a minimum, basic modem functionality, and 
sufficient memory to run the software to interface with ALCS 30. The present 
invention does not provide an operating system - it is, however, necessary that 

15 the ALCS 30 have interfaces to each of the operating systems with which it 
operates, and the necessary accesses and authorisations, so that it can issue 
appropriate commands to the card and device operating systems to load and 
unload applications and related tasks. It need not, and for security reasons it is 
preferred that it does not have authorisation to, for example, alter PIN numbers, 

20 alter issuer cryptography, or monitor in any way the substance of 
communications from the applications to any external parties with which they 
communicate. 

One way to implement the ALCS 30 to allow it to perform its lease 
management tasks, is for card agent software to be loaded on each participating 

25 smartcard. This software needs to provide a consistent interface to the terminals, 
so that each terminal does not require different software to communicate with 
and utilise the ALCS 30 functionality on each type of smartcard. 

A preferred implementation, however, is to not require any special 
software on each card, but rather to provide appropriate terminal interfaces, so 

30 that ALCS 30 instructions are implemented using the commands within each 
card's operating system. Thus, the ALCS 30 via the terminal does not usurp the 
normal operating system protocols and interfaces - it simply utilises them to 



perform the tasks required for the operation of the ALCS. 

Terminal 1 1 includes various software components necessary to perform 
the ALCS tasks required. It is noted that in addition it is loaded with the 
software necessary to perform its normal tasks, for example as a financial 
services .terminal or other smartcard reading device. The ALCS functionality is 
an application provided in addition to the existing software, not a replacement 
for it. 

A terminal agent 63 is required to provide a consistent interface to 
terminal applications for access to the ALCS 30 functionality of smartcards, 
regardless of the type of card inserted. 

The Terminal Agent 61 also provides a consistent interface for managing 
all terminal functionality to the remote ALCS back-end server. 

The system will conveniently provide a collection of standard application 
groupings and a set of interfaces that have to be met by each application 
belonging to a group, shown as box 64. The applications supported by the 
terminal are shown generally as 70. 

The application groups may include, for example: 

• Payment Applications which handle different forms of payment 
such as Credit, Debit, Stored Value etc, 

Communication applications which facilitate external 
communications and network protocol conversions, 

• Advertising Applications for displaying and manipulating 
advertising messages on a terminal display, 

• Management Applications to facilitate device management such as 
configuration and gathering of statistics, 

Identification Applications which assist in authenticating a user, 
handle the personal details and security checks, 
Directory Applications which permit the cataloguing and searching 
of the available applications on a device, 

Security Applications which can place a terminal into a number of 
different security modes and 

Ordinary/Legacy applications that do not co-operate with any other 
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application on the system and operate in a legacy fashion. 
Applications can be grouped into a collection. For example a utility 
company, a bank and an insurance provider may wish to bundle their 
applications for distribution together. They will be identified by a collection 
5 trading name. If a terminal detects that a smartcard with a known X-Collection 
identifier has been inserted, it will run the specific X-Collection menu. 
Alternatively, the terminal may display a menu structure and the selection of all 
applications that are loaded onto it. 

Software interfacing to the Issuer host will assist in automating such 
10 things as submitting new real estate, confirming acceptance of lease requests 
by tenants and anything else that would have to be done manually by Issuer 
operators via ALCS graphical interfaces. 

Software to interface to application providers would assist in the 
automated searching of real estate and submission of lease requests, automatic 
1 5 submissions of applications to the rental property, etc. This would reduce the 
need for manual browsing by providers of the ALCS Application Provider GUI 
screens. 

To improve the ability of the ALCS software to communicate with devices 
and in particular smartcards, an interface to transaction acquirers is desirable. 
20 Via this interface the ALCS can notify a transaction acquirer when a particular 
device comes on-line, to tell the device to also contact the ALCS for 
management purposes. This assists the flexibility and functionality of the overall 
ALCS solution. 

Note that in many cases the transaction acquirers may be issuers. 
25 The ALCS must co-exist in a mixed, legacy environment of various 

communication protocols and networks. For example, some of the interfaces 
include EFTPOS, AS2805, HDLC, Synchronous networks and SNA Networks. 

Communication speeds end-to-end in practice vary dramatically starting 
from only 1200bps. Also, much of the front-end equipment (terminals/ 
30 smartcards), is not necessarily on-line but rather comes on-line only when a 
transaction occurs. This ALCS will need to accommodate this in any 
implementation. 
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ALCS Functions 

The ALCS functionality, can be grouped into the following areas: 

• Interfacing to Device Issuers and Application providers, 

• Device Real Estate Management, 
5 • Application Management, 

• Security Management, 

• Billing and 

• Advertising Management. 
Interfacing to Device Issuers 

10 Smartcard issuers and/or terminal issuers, require an interface to the 

ALCS in order to inform the ALCS of available real estate for leasing and their 
specific requirements as far as tenants are concerned. The further illustration of 
the present invention will be with respect to the applicants Privacy Host 
implementation. It will be appreciated that this is only one way in which the 

1 5 invention can be implemented. 

An interface can vary in sophistication, from a simple hand signed letter of 
agreement and an issuer supplied floppy disk with the device details, to a fully 
automated system. In an automated system, the issuers' computers directly 
interface and communicate to the ALCS for the purpose of informing the ALCS 

20 of real estate availability. 

Issuers will in addition provide classification for their devices. 
Classifications can be based on demographics (age, income level etc.) or any 
other issuer choices. These classifications will be used by application providers 
for device selection. 

25 Figure 3 illustrates the components of the process of a device issuer 

providing real estate for lease. The device issuer 54 supplies details of the 
available real estate, or devices, to the Privacy Host server 40. This then 
supplies the relevant details for secure storage on the Privacy Host database 
38, including for example the number of devices, the details of the devices, the 

30 relevant demographic details, and the number of bytes of memory available. 
The device issuer 54 also provides specific tenant requirements to the privacy 
host server 40 which are then stored in the database. For example, the issuer 
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may not want any other travel applications loaded, as this would compete 
against its primary application, but may be particularly interested in financial 
services applications being loaded. 

In addition Device Issuers will wish to see the status of their real estate at 
5 any point in time. This information can be provided by the ALCS in several 
ways. Periodic reports, a WWW on-line interface or direct access between 
ALCS database and the Device Issuer database. 
Interfacing to Application Providers (Device Tenants) 

Potential tenants - those wishing to provide applications for the devices 
10 -need to be able to search for the appropriate real estate that suits their 
demographic or other need and supply the applications for down-loading and 
occupation of the real estate. 

The interfaces the ALCS needs to provide to prospective tenants include 
software to locate the required real estate, software to apply for a lease and 
1 5 submission of the applications. It is preferred that a facility for application signing 
and Tenant authentication is provided. 

These interfaces may range from graphical WWW screens to automated 
search and submit mechanisms between the ALCS and Application Providers' 
computers. 

20 Figure 4 illustrates a process in which an application provider 53 

requests cards for rent. Application provider 43 logs on to the Privacy Host 
system 40. Using search criteria and particular demographic details they select 
the type and number of cards that are of interest. A sample screen for this 
purpose is shown in figure 5. Using a simple GUI, various options as to price, 

25 device type, demographics, memory requirements, etc can be entered. 

Figure 6 illustrates a report screen generated by the Privacy Host system 
40 after searching the Privacy Host database 38. This shows the number of hits 
on the various criteria selected by the application provider 53. At this stage, the 
application provider 53 could elect to alter the criteria and redo the search, if 

30 insufficient hits were found. On the basis of the report, the application provider 
53 can decide to submit a rental request, by clicking the submit button. This is 
then sent to the one or more card issuers 51 A, 51 B whose cards meet the 
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criteria. It is emphasised that the present invention is readily implemented in a 
multiple issuer, multiple operating system environment, allowing for real estate 
to be rented which best meets the criteria of the application provider 53, whether 
this is all on cards from one issuer or on only a few cards from many issuers. 
5 Once the approvals have been given, privacy host sends a confirmation 

to the application provider, for example as shown in figure 7. This may 
conveniently include a public key for a public/private key encryption system, 
which the application provider 53 uses to encrypt the applications and then 
submit these to the Privacy Host system 40. The applications can then be 
10 downloaded as the cards in question come online, as will be discussed further 
below. 

Device Real Estate Management 

This is one of the central functions of the ALCS. There is a need to be 
able to manage the space on each device so as to enable multiple applications 
1 5 from different parties to be resident, without interfering with each another. The 
real estate must be allocated and J dynamically to the different 

participants in the scheme. The participants are acting in the role of "device 
tenants" by supplying their applications to reside on the devices. 

The system will also need to keep track of such things as number of 
20 vacancies on each device, expiry of lease for an application, length of tenancy 
of each application and similar information.' For example, figure 15 shows a 
sample screen reporting lease agreements, providing details such as term, 
tenant, and number of devices; figure 16 shows a sample screen reporting 
devices by issuer which are controlled by the ALCS; figure 17 shows a sample 
25 screen reporting tenants current on the system; and figure 18 shows a sample 
screen reporting vacant property on the system. 

The participants may also require various other reports, which can be 
readily provided using standard database query and reporting software, for 
exiample: 

30 • An issuer makes changes to their entries, removing, adding and 
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modifying real estate as they see fit. 

An issuer wishes to see a breakdown of the number of devices he has 
submitted for lease. 

An issuer wishes to see how many of their devices have been leased and 
to whom. 

An issuer searches for devices based on technical criteria such as device 
operating system and demographic criteria such as physical location. 
A device issuer wants to query know how much real estate is still vacant. 
An issuer requests information on the most popular devices by usage. 
An issuer requests information which shows the most popular physical 
device locations. 

an issuer requests information showing which leases are due to expire 
and what property will be made vacant. 

A application provider requests information listing the whereabouts of 
their applications with the information being grouped by physical location, 
real estate category and demographic breakdown. 
A application provider requests information on the issuers they are 
dealing with. 

A application provider requests information on their leases including 
length of lease and how much time before certain leases expires. 
A application provider wishes to find out how many times their 
applications have been used on each device. 

The operator lists all Issuers that are participating in the ALCS together 
with information on their Real Estate. 

The operator lists all tenants together with information on their status. 

The operator lists all the property that is currently vacant. 

The operator extends the lease for an application on a given set of 

devices. 

An operator retrieves information and determines who the best Issuers 
and tenants are. 

An operator examines information on tenant lease requests that could not 
be fulfilled. 
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• An operator requests information to identify if any problems occurred 
when attempting to occupy property by applications. 

• An operator requests information to identify if any problems occurred 
when trying to vacate property by applications. 

5 Device Rebuilding 

If a smartcard is lost or damaged, the ALCS is preferably able to rebuild 
and re-install on the real estate all the applications that were previously present 
using its database or links to external Application provider databases. These 
applications will be in a brand new state. Restorations of any loyalty points, 
10 transaction information or any other data that was accumulated over time, will 
need to be done by the application provider. 

It is important to note that whilst preparing a batch of cards for issuing, 
they usually go through the following processing steps: 
1. Initialisation, 
15 2. Profile Preparation and 

3. Personalisation. 

Initialisation is the process where all the common data of a batch of cards 
is located onto them. Profile preparation is the phase where an Issuer 
associates cards to business organisation. Particular applications are loaded 

20 onto the card as the Issuer sees fit. Personalisation is the process where 
cardholder specific information is loaded onto a card. This phase associates 
a card to a user. The ALCS initially will not replace this functionality but ensure 
that after a lost device is replaced with a" new initialised and personalised 
device, that it can accurately replace the additional applications that were 

25 residing on the device at the time of loss. 
Application Management 

The system manages the applications that will reside on the devices 
including: 

• Distribution of applications, 
30 • Lifespan of applications, 

• Application Providers submitting applications for devices, 

• Storage of applications, 
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• Loading and Unloading of applications. 
Different applications can execute on different devices thus the ALCS needs to 
be able to manage this mix and match of application to device hardware 
architecture. 

5 Figure 8 shows a sample screen report for a particular application, 

providing details of which devices it is loaded onto, the period of lease 
remaining, the device owner, and the date the application was loaded onto each 
device. 

Figure 9 illustrates the interactions necessary when the operator of the 

1 0 Privacy Host system wishes to extend the lease of space for an application on a 
given group of devices. The diagram show various elements of the system - the 
Privacy Host database, the Privacy Host operator, the existing interface ( legacy 
interface) to the terminal, and the terminal - as vertical lines, with time increasing 
down the graph and communications shown as lines between the elements. 

15 The operator sends a signal to inform the given device that it should 

contact Privacy Host, to the legacy interface, which is then forwarded to the 
terminal. When the terminal goes online, it signals this to the Privacy Host 
operator, which then sends a signal extending the application lease to the 
terminal. The terminal confirms this to the Privacy Host operator, which then 

20 updates the Privacy Host database. 

Figure 10 illustrates, in a similar way to figure 9, the interaction of devices 
when a request to delete applications is sent. The operator sends a signal to 
inform the given device that it should contact Privacy Host, to the legacy 
interface, which is then forwarded to the terminal. When the terminal goes 

25 online, it signals this to the Privacy Host operator, which then sends a signal 
deleting the application lease to the terminal. The terminal confirms this to the 
Privacy Host operator, which then updates the Privacy Host database. 

Figure 1 1 shows the interaction of devices when an operator wishes to 
obtain details of a device. The operator sends a signal to inform the given 

30 device that it should contact Privacy Host, to the legacy interface, which is then 
forwarded to the terminal. When the terminal goes online, it signals this to the 
Privacy Host operator, which then sends successively signals requesting the 
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amount of free space, the current operating system, a list of currently loaded 
applications, and the card owner. It will be appreciated that the queries could 
vary if required. The terminal reports the answers to the Privacy Host operator, 
which then updates the database. Figure 14 shows a sample report screen 
5 which tabulates the configuration of devices and shows their current status. 

Figure 12 illustrates a more complex process, in which a selection of 
cards have a debit application loaded, and an application provider wishes to 
add a loyalty application. The vertical lines represent elements of the system, 
similarly to figure 9. The application provider conducts a search (1), and on the 

10 basis of the results requests permission to load on certain devices (2). After 
approval is obtained (3), the public encryption keys are provided (4), the 
application is encrypted (5), and is then submitted to the Privacy Host manager 
via the real estate screen (6). The Privacy Host manager sends a signal to the 
legacy interface requesting the ( or each specified) device to contact the Privacy 

1 5 Host manager(7). When the device is inserted into a terminal and is online, it 
signals the Privacy Host manager and sends a request to get the application (9). 
This is then downloaded from via the terminal (10,11,12). The terminal then 
sends a similar request to download the terminal application for the loyalty 
scheme(13-17). 

20 Figure 13 shows a sample screen report of applications which have been 

authorised for downloading, but have not yet been loaded. 
Device Access Control 

The ALCS needs to control who has access to which devices. The 
devices act as a security gate to the real-estate. It is necessary for the 
25 application provider to be given permission to access a particular set of devices 
before they are permitted to become lessees of device real-estate and deposit 
applications for execution. 

The ALCS System will keep track and manage access permissions for 
the different groups of devices in accordance with arrangements in place 
30 between the various parties. 

In most cases the owner of a terminal is not necessarily the issuer of the 
smartcard which is being used in the terminal. The ALCS will need to cater for 
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all the different access scenarios. 

It is envisaged that ALCS card and terminals users will fall into one of 
several categories: 

• Issuers - Can have applications residing on the devices and extra 
5 permissions. 

• Tenants - Will have applications residing on the devices and 
permission to use all the card services. 

• Members - Can use the device services but have no applications 
physically residing on a device. (For example a smartcard 

10 member may be able to use the encryption facilities of the card 

from an application residing on a terminal). 

• Visitors - Can only use any publicly available services and cannot 
have any code residing on devices. Such a public service may for 
example be the use of a terminal's modem functionality. 

15 Services for Visitors could be anything ranging from proprietary to a 

standards based service. The distinguishing factor is that the ALCS will not be 
involved in the management of any such miscellaneous services, as it does not 
involve applications residing in non-volatile memory. 
Billing 

20 The ALCS will charge lessees for their use of Card Real Estate and 

terminal real estate as per agreements. In addition the ALCS will facilitate the 
charging of a fee against revenue for the service it provides. The system 
contemplates multiple layers of billing, and that Periodic Bill reports and charges 
will be sent to participants. These aspects may be implemented via conventional 

25 billing software based on reports sent from the Privacy Host manager. 
Advertising Management 

The system can readily provide facilities for advertising to appear on 
terminal screens via applications. The rights to use these advertising facilities 
and the cross-advertising agreements that will have been agreed to by the 

30 different parties, will be managed, executed and adhered to by the ALCS. 
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Constraints 

Various practical constraints will apply to the system, some of which are 
set out below, and need to be considered in any practical implementation. 
Some terminals will not be on-line and will not support dial-in functionality. This 
may limit the range of applications that can be downloaded to them. In addition 
a smartcard, can only have a new application loaded onto it after it has been 
inserted onto a terminal by ai user. 

Measures will need to be put in order to ensure that periodically at least, 
these devices can come on-line. Such measures include system interfaces with 
a terminal transaction acquirer. This will permit the ALCS to use the acquirer's 
link with the terminal as a means of contacting the unit. Alternatives include 
periodic call ups by a terminal to the ALCS Server, and inducements to card 
holders to occasionally insert their smartcard into an on-line terminal for 
updating. 

Existing terminal applications to a large or smaller extent may have to be 
re-written in order for them to make use of the ALCS functionality. Existing non- 
modified applications will be classified as legacy and the ALCS architecture will 
ensure that they can execute in their present form. They will not though be 
managed by the ALCS system. Existing multi-application smartcard based 
applications will be able to take part in the ALCS unmodified. 

The ALCS system will make a best effort to ensure that applications only 
execute and take up the memory space they have paid for. In addition the 
ALCS will try to ensure that applications do not infringe on each other. To 
enforce these requirements though, the ALCS system needs support from the 
device operating system and hardware. A Multos based smartcard 
environment, can support these requirements and thus the ALCS will make use 
of them. Other terminal hardware and operating systems may not offer this level 
of support and thus the ALCS will only be able to make a best effort attempt at 
safeguarding device space and applications. 

It will be appreciated that many modifications and variations are possible 
within the spirit and scope of the present invention. 
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THE CLAIMS DEFINING THE INVENTION ARE AS FPU OWfi - 

1. An application control system for use in an environment including a 
plurality of smartcards and terminals, a plurality of host systems each adapted 
to interact with some or all of the smartcards and terminals, said smartcards and 
terminals including a multiple application operating system, 

said system comprising at least card software located on said cards, 
terminal software located on said terminals, control software located on one or 
more remotely located processing devices, and a database in communication 
with at least said remotely located processing devices, said database including 
details of which applications are permitted to be loaded onto which cards and/or 
terminals, said card software, said terminal software and said control software 
co-operating so as to utilise the operating system on each card or terminal to 
download and/or delete applications on each card or terminal, such that said 
system provides a software system which enables the remote loading and 
deletion of applications independent of the operating system on each card or 
terminal. 

2. A system according to claim 1, wherein said control software in 
cooperation with said database maintains details of the cards and terminals 
forming part of the system, a set of possible applications which can be loaded 
onto the cards and/or terminals : and details of which applications are permitted 
or required to be loaded onto selected cards and terminals. 

3. A system according to claim 3, wherein when a card or terminal is 
brought on line with the system, the system identifies the card or terminal and 
determines whether a new application needs to be loaded or an existing 
application needs to be removed, and the control software in cooperation with 
the card and/or terminal software cooperate to issue appropriate commands to 
the smartcard or terminal operating system to load or delete said applications . 
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4. A process for arranging the lease of capacity on one or more smartcards 
for utilisation by an application provider, for use in an environment including a 
plurality of smartcards and terminals, a plurality of host systems each adapted 
to interact with some or all of the smartcards and terminals, said smartcards and 
terminals including a multiple application operating system, and a system 
comprising at least card software located on said cards, terminal software 
located on said terminals, control software located on one or more remotely 
located processing devices, and a database in communication with at least said 
remotely located processing devices, said database including details of which 
applications are permitted to be loaded onto which cards and/or terminals, said 
process including the steps of: 

(a) the application provider requesting a search, using a set of user 
defined criteria, of said database in order to locate terminals and/or devices on 
which the provider may wish to load an application; 

(b) the control software conducting a search and returning a report to 
the application provider; 

(c) the application provider confirming his desire to lease space to the 
control software; 

(d) the control software requesting approval from the one or more card 
and/or terminal owners for the application provider to lease space; 

(e) the card and/or terminal owner sending an approval to the control 
software; and 

(f) the control software sending a confirmation that the lease has 
been approved to the application provider. 

5. A process according to claim 4, wherein the process further comprises 
the steps of: 

(g) the control software sending an encryption key to the application 
provider to enable their submission of their application for downloading to the 
specified cards and/or terminals; 

(h) the application provider sending a copy of their application 
encrypted using the specified key to the control system; and 
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(i) the control system updating the database so that it indicates that 
the application is to be loaded onto the specified cards and/or terminals when 
next they are online with the system. 

6. A smartcard or terminal adapted to be utilised in the system of any one of 
claims 1 to 3. 

7. A smartcard or terminal adapted to be utilised in the process of claim 4 or 
5. 

8. A smartcard or terminal software product adapted to be used in any one 
of claims 1 to 5. 
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